What Designers Can Learn From Coders
What Designers Can Learn from Coders
For the past decade, I've worked where design meets code. Agile ceremonies might seem odd to designers, but they have a lot to teach us. Here are key lessons designers can learn from developers, based on stereotypical observations of each group.
1. Continuously Improve Collaboration
Agile practices focus on enhancing teamwork. Retrospectives, held regularly, allow teams to discuss and improve collaboration objectively. This practice fosters a culture where even difficult issues can be raised constructively. The key to this is having stable teams that continuously refine their methods. In retrospectives, it's understood that feedback isn't personal; it's about improving team dynamics, communication methods, and chemistry. Regularly scheduled time for these discussions ensures that even uncomfortable topics can be constructively addressed.
2. Team Ownership Over Individual Work
We all remember the designer who hoarded files on their own computer, sharing only the final design. When they were out sick, no one could edit the files because they were inaccessible. Good development practices emphasize code management and daily sharing of in-progress work. No one 'owns' a particular functionality; everything is developed collaboratively. Tools like Abstract, Kactus, Invision Studio, and Figma have made it easier for designers to share files continuously and manage versions. This approach fosters a sense of collective ownership and ensures that work can continue smoothly, even if someone is unavailable.
Read more about Code Ownership by Martin Fowler.
3. Help Team Members Grow
It's often quicker to do things ourselves, but helping and teaching others is beneficial in the long run. Developers understand this well, even if it’s sometimes communicated poorly. They encourage team members to look things up, modify code themselves, and learn through doing. Instead of spending 10 minutes fixing an issue, they might spend a day teaching someone else to fix it. Similarly, designers shouldn't get stuck on pixel-perfect specs but should explain the concepts behind typography, animations, and interactions. Sometimes, it's even beneficial to let developers create a rough version of a design based on minimal specs, then refine it together through discussion.
Pair programming and swarming (where everyone stops their work to focus on solving the biggest problem together) are practices that can be mirrored in design for collaborative growth and problem-solving.
4. Create Reusable Modules
Design systems are the latest buzzword. Some might say there's nothing new about them; designers have always built updateable systems in Sketch, Photoshop, or InDesign. These structured file systems enable modular design and efficient spec production. Developers, similarly, have long used component libraries to manage and update project styles from a single location. Design systems finally unify these parallel approaches, naming components consistently, updating both spec systems and UI components simultaneously, and sharing components across projects.
Read more in the Design Systems Handbook.
5. Make Workflow Visible
You've likely seen a developer's Kanban board covered in post-it notes and detailed descriptions. It's a common misconception that Kanban is just a task management method. Kanban is actually about improving work processes. Making tasks and workflows visible on a large board changes how we think and talk about work. When steps are written in large letters on a whiteboard, they can be easily changed. If tasks pile up in one column and fall to the floor, workflow issues become apparent. Making workflows visible encourages continuous improvement.
Learn more about the principles of Kanban.
6. Document Silent Practices
In new coding projects, the root directory often contains several README files describing team workflows, silent practices, and collaboration expectations. These files detail how code should be indented, how to handle intermediary work, how to merge code into the main project, and how to give and receive feedback. These READMEs act as a shared agreement on project practices. Changing them is like changing any other code: make the change and submit it for review. This makes it easy for new team members to get up to speed, as everything they need to know is documented in one place.
By adopting these practices, designers can enhance teamwork, efficiency, and project outcomes. These insights are based on stereotypes and are meant to highlight areas for potential growth and improvement.